Recently, we have seen increasing activities of denial of service (DoS) attacks against online services and web applications to extort, disable or impair servers. Sophisticated DoS attacks are increasingly focusing not only on low level network flooding, but also on application level attacks that flood victims with requests that mimic flash crowds. Application level DoS attacks refer to those attacks that exploit application specific semantics and domain knowledge to launch a DoS attack such that it is very hard for any DoS filter to distinguish a sequence of attack requests from a sequence of legitimate requests. Two characteristics make application level DoS attacks particularly damaging. First, application level DoS attacks emulate the same request syntax and network level traffic characteristics as that of the legitimate clients, thereby making them much harder to detect. Second, an attacker can choose to send expensive requests targeting higher layer server resources like sockets, disk bandwidth, database bandwidth and worker processes.
There are two major problems in protecting an online e-Commerce website from application level DoS attacks. First, application level DoS attacks could be very subtle, making it very difficult for a DoS filter to distinguish between a stream of requests from a DoS attacker and a legitimate client. It would be very hard to distinguish DoS attack requests from the legitimate requests even if a DoS filter were to examine any statistics (mean, variance, etc.) on the request rate, the contents of the request packet headers (IP, TCP, HTTP, etc.) and even the entire content of the request packet itself. Further, the subtle nature of application level DoS attacks make it very hard to exhaustively enumerate all possible attacks that could be launched by an adversary. Hence, there is a need to defend against application level DoS attacks without knowing their precise nature of operation.
One way to defend from DoS attacks is to permit only preauthorized clients to access the web server. Preauthorization can be implemented using SSL (secure sockets layer) or IPSec (IP security or IPSEC) with an out-of-band mechanism to establish a shared key between a preauthorized client and the web server. Now, any packets from a non-preauthorized client can be filtered at a firewall. However, requiring preauthorization may deter clients from using the online service. Also, for an open e-Commerce website like eBay or Amazon, it may not be feasible to make an exhaustive list of all clients that should be authorized to access the service. Further, it would be very hard to ensure all authorized clients will behave benignly. A DoS attack from a small subset of preauthorized clients may render the server unusable.
Challenge-based mechanisms provide an alternative solution for DoS protection without requiring preauthorization. A challenge is an elegant way to throttle the intensity of a DoS attack. For example, an image-based challenge (Turing test) may be used to determine whether the client is a real human being or an automated script. A cryptographic challenge [see X. Wang and M. Reiter, “Mitigating Bandwidth Exhaustion Attacks Using Congestion Puzzles,” Proceedings of ACM CCS, 2004] may be used to ensure that the client pays for the service using its computing power. However, most challenge mechanisms make both the good and the bad clients pay for the service, thereby reducing the throughput and introducing inconvenience for the good clients as well. For instance, an image-based challenge does not distinguish between a legitimate automated client script and a DoS attack script.
An effective solution to defend against DoS attacks is to filter attack requests at the earliest point (say, the website's firewall), before it consumes much of the server's resources. The attack requests arrive from a large number of geographically distributed machines, and thus cannot be filtered on the IP prefix. Some websites require password and login information before a client can access the website. However, checking the site-specific password requires establishing a connection and allowing unauthenticated clients to access socket buffers and worker processes, making it easy to mount an attack on the authentication mechanism itself. Some sites use strong digital signature based transport level authentication mechanisms [e.g., secure sockets layer, SSL]; however, the complex server-side computations required for verifying a digital certificate allow an adversary to target the handshake protocol for launching DoS attacks. In general, authentication mechanisms that operate at a higher layer in the networking stack allow an attacker to target lower layers.
Some websites may use message authentication codes (MAC) based IP level authentication mechanisms like IPSec. IPSec with preconfigured keys allows packets from unauthenticated clients to be dropped by the firewall. Hence, unauthenticated clients cannot access even low level server resources like socket buffers and transmission control blocks (TCBs). However, IPSec breaks client transparency in several ways: (i) Installing IPSec requires changes to the client-side networking stack, (ii) Installing IPSec requires superuser privileges at the client, (iii) IPSec permits both manual key set up and key exchange using the Internet key exchange protocol (IKE). The IKE protocol uses the Diffie-Hellman key exchange protocol. Similar to digital signatures, this protocol imposes a heavy computational load on the server, thereby allowing an adversary to target the IKE protocol for launching DoS attacks. (iv) Manually setting up shared keys circumvents the expensive IKE protocol. However, manual IPSec key setup requires superuser privileges at the client.
There is an inherent conflict between using client authentication for defending against DoS attacks and client transparency. It appears that an effective defense against DoS attacks must operate at lower layers in the networking stack so that the firewall can filter a packet before it can consume much resources at the server. On the other hand, introducing an authentication header at lower layers in the networking stack annuls client transparency, usually by requiring changes to the client-side network stack and by requiring superuser privileges at the client. Therefore, there is a need for a solution that overcomes the aforementioned shortcomings.